home *** CD-ROM | disk | FTP | other *** search
/ Delphi 2.0 - Programmer's Utilities Power Pack / Delphi 2.0 Programmer's Utilities Power Pack.iso / a_to_d / dbfilt15 / readme.txt < prev   
Encoding:
Text File  |  1996-09-15  |  8.0 KB  |  169 lines
  1.                TUZFILTER V. 1.05 - free filtering on any DataSource 
  2.                ====================================================
  3.  
  4.  
  5. Hi, out there in the wilderness. Here may come a the solution for many of your
  6. problems, related to filtering and indexing under DELPHI.
  7.  
  8. This little component implements a BDE-level filter, based on a callback into
  9. your form's/unit's code, much like those QSort.-callback were.
  10.  
  11. The callback function does all the filtering stuff, ie. detemines, whether the
  12. current record in scope is to be included or excluded, INDEPENDENTly of any
  13. index-settings, data-links, 1:m table links or whatever and LIVE.
  14.  
  15. Installation:   after unpacking the ZIP-file, you'll find following files:
  16.  
  17.    -> FILTDEMO.*     a little demo-application
  18.    -> FLTDEMO1.*     unit for FILTDEMO
  19.  
  20.    -> DBFILTUZ.INT   documentation (installation AND HOW TO USE)
  21.    -> DBFILTUZ.DCU   TUZFilter VCL-component (see installation section in
  22.                      DBFILTUZ.INT)
  23.    -> DBFILTUZ.DCR   resource-file for DBFILTUZ.DCU
  24.  
  25.  
  26. RUNNNING the example in FILTDEMO:
  27.  
  28.    following prerequisites have to be fullfilled to run FILTDEMO "out of the
  29.    box":
  30.  
  31.    ->    A valid DBDEMOS-alias in you BDE-configuration (CUSTOMER.DB and
  32.          ORDERS.DB will be accessed) must exist.
  33.    ->    DBFILTUZ.DCU m,ust be installed to your COMPLIB.DCL (see installation
  34.          section "how to install" in DBFILTUZ.INT)
  35.  
  36.  
  37. FREEWARE:   This component is FREEWARE according to the terms in DISCLAIMER'S
  38.             NOTE in DBFILTUZ.INT.
  39.             Source can be obtained from author (see contact address at end of
  40.             this file).
  41.  
  42.  
  43. ADDITIONAL INFO, READ CAREFULLY:
  44. ================================
  45.  
  46.    I don't know, whether to state this as a "known bug" or not, but at least
  47.    the following hint might be very helpful, bioth for security of code and
  48.    for speed:
  49.  
  50.    DON'T CODE a "Application.ProcessMessages" line into your filterevent-handler
  51.  
  52.    Doing so, might confuse BDE which callback-events are "still to be processed"
  53.    and which alredy are processed, leading into recursive calls of the filter-
  54.    event handler until memory is low and BDE will GPF (IDAPI01.DLL 0003:xxxx or
  55.    0001:xxxx).
  56.    This GPFs might freeze WIN as well as throw backl the hard way onto DOS-prompt,
  57.    leaving tables open, records locked and so on.
  58.  
  59.  
  60.  
  61.  
  62. HISTORY of changes:
  63. ===================
  64. VERSION 1.05:  hmmm, shoudl I call thisone a BUG-fix ? Well decide youself,
  65.                here is what's happening why and how I worked around.
  66.                Although V 1.04 worked very well and properly when PDX-tables
  67.                were used, two users reported, that, when issuing a .LAST on a
  68.                filtered dBASE-table (i.e. by a TDBNavigator-control), their
  69.                programs threw an "at end of table exception", though neither
  70.                the EOF-condition really was true, nor any erratic behavior
  71.                took place, just that ugly nasty exception-box in front of your
  72.                users'r eyes ....
  73.                Richard Lebeda (tanks to him) provided me with a minimal sample,
  74.                to reproduce that "feature", which _only_ occurs, if a BDE-
  75.                callback filter ion dBASE-tables is aborted (which is done
  76.                behind the screens, to get .FIRST/.LAST worling) and the table
  77.                was set to it's last record. This IMHO is a bug in
  78.                IDDBAS01.DLL, because aborting a callback-filter under no
  79.                circumstances should result in a EOF or BOF condition and for
  80.                sure it does not, when IDPDX01.DLL is used for PDX-tables.
  81.  
  82.                Well I can't rewrite the IDDBAS01.DLL but I found a workaround,
  83.                which at least hides those ugly exceptions before the
  84.                applications user's eyes.
  85.                That workaround is done by temporarily catching exceptions,
  86.                when a filter for dBASE-tables is up to be aborted (don't be
  87.                concerned, the original exception-handler is restored immediatly
  88.                after that EOF-exception has been catched).
  89.                This avoids the EOF-exception trap, when your program is
  90.                running in "real live", but it can't avoid that exception,
  91.                under following circumstances:
  92.  
  93.                -> dBASE table is set to last record
  94.                -> filter is active
  95.                -> OPTIONS | ENVIRNMENNT "stop on exceptions" is set TRUE
  96.                -> DELPHI's debugger is running
  97.  
  98.                for DELPHI's own exception-catcher (invooked by that "stop on
  99.                exceptions" switch) will trap the exception, _before_ it
  100.                reaches the "exception-killer" in TUZFilter. So, while
  101.                designing/developing your program and matching the above
  102.                conditions, yout might have to resume your program by F9/run-
  103.                btn, when this exception will occur.
  104.  
  105.                Sorry, for beeing unable to provide you with a better solution,
  106.                but, if I would prevent from aborting the filter when a .LAST
  107.                move on dBASE-tables is issued, you won't see the last record,
  108.                and I think a some of those nasty exception during development-
  109.                cycleboxes are much better, than embezzling the last record.
  110.  
  111.                
  112.                
  113. VERSION 1.04:     BUG-fixes:
  114.                   -> .LAST-method resulted in an empty result set/first record
  115.                   -> adding a new record might result in an empty result set
  116.  
  117.    thanks to Frank BĪ£urle, who reported the bug on the .LAST-method on a
  118.    dataset. This bug occurred when acting as follows:
  119.  
  120.       -> either use the mouse to drag the vertical slider thumb to it's lower
  121.          end position (will result in an .LAST command on the dataset)
  122.       -> or issue the .LAST command by keybord with crtl-end
  123.  
  124.    in both situations, V 1.03 returned an empty result set. This bug has been
  125.    fixed and in addition some similar or related bugs has been fixed too:
  126.  
  127.       -> crtl-end or dragging the vert-thumb to the lower end on a DETAIL-
  128.          table resulted in moving to the first instead of the last record in
  129.          detail table (fixed)
  130.       -> adding/inserting a new rceord into a filtered dataset may too have
  131.          resulted in an empty resuult set under V 1.03 (fixed too, now works
  132.          as expected)
  133.          
  134.  
  135. VERSION 1.03:     BUG-fix, speed-improvement and initial default-setting
  136.  
  137.    bug-fix:   When using two master-datail linked tables like in the demo-form, and
  138.    "quick-scrolling" thru the nmaster-tables by mouse (holding the down-arrow of
  139.    the grid pressed), a "not enough memory-error" occurred, this should be fixed
  140.    now (tnx to Peter Gentes, pointing me in rioght direction).
  141.    Additionally, a similar bug lead to a GPF in IDAPI01.DLL, when a master-
  142.    record with _no_ detail-recs was reached and the two tables additionally
  143.    were liked by PdX' referential integrity, should be fixed too.
  144.  
  145.    speed-imporvement:   the detail-table isn't rebuild after every single
  146.    record-skip in the master-table which (at least, when scrolling by
  147.    keyboard) should improve scrolling speed.
  148.  
  149.    initial default setting:   I just added a default setting for all
  150.    TUZFilter-properties when you draw a new component on your form.
  151.  
  152.  
  153. VERSION 1.02:     correction in FLTDEMO1.PAS uses-clause
  154.  
  155.    so sorry, V 1.01 did include a typo. The uses-clause in FLTDEMO1 referenced
  156.    a component DBFILTER (which was the original name of DBFILTUZ suring
  157.    develpment, but has changed due to the fact, that I found another component
  158.    already using that name). Unfortunatly, I just added the DBFiltUZ
  159.    forgetting to delete the now obsolete old reference.
  160.    In V 1.02 this has been changed, so compiles will no more break down with a
  161.    "component not found" error for the obsolete refernce. That's the only
  162.    change for V 1.02.
  163.  
  164.  
  165. may the gods of the olymp smile on you ...
  166.  
  167. bye UZ/2       CIS: 100271,313
  168.  
  169.